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Abstract 

Priority inversion occurs when a process is delayed by the actions 
of another process with less priority. With atomic transactions, the 
concurrency control mechanism can cause delays, and without taking 
priorities into account can be a source of priority inversion. In this 
paper, three traditional concurrency control algorithms are extended 
so that they are free from unbounded priority inversion. 

Keywords: Priority inversion, concurrency control, real-time da- 
tabases. 

In a real-time system, the actions of some process may be more urgent than 
those of another. For example, the first process may need to synchronize 
with a physical process and sp must must a deadline. If both processes have 
access to common resources that cannot be shared, the less urgent process 
may delay the more urgent one by holding onto the resource. This situation 
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is commonly called a priority inversion [7,4]. There are several approaches 
to this problem, but the simplest is to simply force the less urgent process 
to relinquish the resource in favor of the more urgent process. Priority 
schedulers are an example of the implementation of this strategy 1 . 

In database management systems, the concurrency control mechanism is a 
scheduler through which a process may be delayed by the actions of another 
process. In this paper, some common concurrency control algorithms are 
extended so that priority inversions are detected and broken. Transactions 
will inherit their process’s priority, and a transaction will be aborted or 
delayed if it could delay a more urgent transaction. A transaction is delayed 
while a less urgent transaction is aborted; we assume that aborts have a 
fixed overhead and can be taken into account when determining the running 
time of a transaction. 

In this paper, we assume that the transactions submitted by a process are 
not known a priori. The schedulers presented here guarantee that the ac- 
tions of a transaction cannot be delayed for more than a bounded time by 
the actions of transactions with less priority. A transaction, however, may 
be starved by the actions of transactions with more priority. In practice, 
these kinds of concurrency control algorithms are important for data base 
systems that support real-time transactions ([8], [1]). They are also im- 
portant for real-time process control problems with concurrently accessed 
shared data. 

We make the somewhat unusual assumption that priorities are assigned 
from a partial order rather than a total order. By doing so, we subsume 
the more typical priorities. We also allow more flexibility in specifying the 
inadmissible delays; with a total order, we may needlessly constrain the 
system. We also assume priorities are statically assigned. 

This is not a practiced paper, in that we have not implemented the algo- 
rithms presented here. Concurrency control algorithms are developed by 
making some decisions on what the equivalent serial order should be. Our 
goal in this paper is to re-examine these decisions when priorities are also 
considered. The amount of complexity some of these algorithms took on is 
surprising. There are some comments on the practical application of these 

1 In this paper, the more urgent process will be said to have more priority than the less 
urgent process. 
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algorithms in the conclusions of the paper. 

In section 1, we describe the properties a concurrency control mechanism 
must have if it is to support transactions with priorities. In section 2 we 
develop a general concurrency control mechanism based on serialization 
graph testing algorithms that detects priority inversions. While easy to 
understand, such algorithms are complex to implement since a directed 
graph must be maintained and updated with each operation submitted to 
the scheduler. 

There are two popular concurrency control mechanisms where the sched- 
uler use a much simpler data structure at a cost of reduced concurrency. 
One ( two-phase locking) delays operations to ensure serializability while 
the other ( timestamp order) aborts operations to ensure serializability. In 
section 3 we show the typical extension of two-phase locking does prevent 
priority inversion when the priorities are drawn from a connected order. In 
section 4 we develop a timestamp order mechanism that detects priority 
inversion. 

In this paper, we follow the notation and system model found in [2]. 


1 Concurrency Control 

Suppose we have a set of processes submitting operations under transac- 
tions to a database scheduler. Each process can submit an unspecified 
number of transactions. 

There exists a partial order >- of priorities over the transactions, where 
Pi >~ P2 means process 1 has priority over process 2. A transaction T, 
submitted by p, has the same priority as p,, so we can also write expressions 
like T\ >• T 2 . The database scheduler knows >- but has no other information 
about the transactions any process will submit. A transaction’s priority is 
static; it cannot be changed by the scheduler or the process submitting the 
transaction. 

Our goal is to devise a concurrency control algorithm that: 

1. ensures the resulting execution is serializable, and 
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2. does not delay nor reject an operation of T, due to the action of T } 
when T, y Tj. 

In general, a scheduler can delay, reject or accept operations in order to 
guarantee the resulting execution is serializable. Typical schedulers abort 
a transaction by rejecting one of its operations. In our schedulers, a transac- 
tion will be aborted when an operation is submitted by another transaction 
with more priority. 

The scheduler will also ensure that properties other than serializability are 
met by the resulting execution. For example, suppose a transaction T 2 reads 
the value of a variable x written by transaction 7\. It is a bad idea to let T 2 
commit before Ti terminates. If T\ decides to abort, T 2 will have committed 
using a value that was not produced by a committed transaction, possibly 
leaving the database in an inconsistent state. So, a scheduler should delay 
the commit from T 2 until T\ decides to commit or abort. The property 
preserved by this delaying action is called recoverability. 

A more dramatic delay is a cascaded abort. Using the above example, since 
T 2 has read x written by 7\, if T\ decides to abort, then T 2 must also 
abort. Again, the scheduler can prevent this condition by delaying some 
operations. For example, the read of x by T 2 could have been delayed until 
it wets after the termination of 7\. 

In both cases, the delay of a transaction ( T 2 ) was caused by a transaction 
(T 2 ) reading a value from an uncommitted transaction (T x ). This is a 
priority inversion when T 2 >- T\. The priority inversion can be represented 
graphically. A reads from graph (or RFG) is a directed graph with all 
currently active transactions as nodes. There are two kinds of edges in 
a RFG. A priority edge from T, to Tj is drawn with a dashed arrow, and 
indicates T, y Tj. A reads from edge from T, to Tj is drawn with a solid 
arrow and indicates there is a value x that was written by Ti and later read 
by Tj. Figure 1 is a RFG showing T 2 y T 3 , T 2 has read from T\ and 7\ 
has read from T 3 . A cycle in a RFG that that contains one priority edge 
represents a potential priority inversion. For example, in Figure 1 aborting 
transaction T 3 will force the abort of T 2 via T\. We will call such cycles 
priority inversion cycles. 

The following theorem argues this more formally. 
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Figure 1: Reads-From Graph 

Theorem 1 If the RFG of a set of transactions contains a priority inversion 
cycle, a priority inversion can occur. 

Proof: Suppose we have a RFG that contains such a a cycle. Let the two 
transactions with the priority edge between them be T{ to T } such that 
T, x Tj. By the definition of a RFG , Tj is active. If T, wishes to commit, it 
must delay until T — j commits; otherwise, the resulting execution would 
not be recoverable. Additionally, if Tj aborts T, must (transitively) abort. 
Both cases represent a priority inversion. □ 

A purely conservative scheduler is a scheduler that never rejects an opera- 
tion (thereby aborting the transaction submitting the rejected operation); 
it only delays operations until it is safe to execute them. Theorem 1 implies 
that there are no purely conservative schedulers that avoid priority inver- 
sion. Suppose such a scheduler existed, and it were submitted the operation 
WjX where p, X pj. By theorem 1, if T, were to submit the operation r,x, 
it would introduce the possibility of a priority inversion. So, the scheduler 
must delay the write operation until it knows that T, will not submit a r;x 
before Tj commits. Since the nature of the transactions submitted by p, 
are unknown to the scheduler, it must delay WjX forever. 
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Theorem 1 doesn’t give a complete characterization of all priority inver- 
sions; it only deals with those due to cascaded aborts. For example, suppose 
we have the following history with T, X Ty 

WiX ; wjx ; wjy, cy Wiy 

At this point, T, must abort due to the actions of Ty otherwise, the execu- 
tion will not be serializable. We will say Tj is ordered before Tj in a history 
H if, in any serial history equivalent to H, Tj occurs before Tj. Suppose 
Tj is ordered before Tj where Tj X Tj. If Tj commits before Tj terminates, 
Tj could submit some operation that conflicts with Tj. This new operation 
violates serializability, and since T } has committed, Tj must abort. To avoid 
this priority inversion, the schedulers developed here will generate histories 
with the following property. 

Definition 1 A history H is priority committed if for all pairs of transac- 
tions Tj, Tj in H, ifTi is ordered before Tj and Tj X Tj, then Cj < Cj. 

A purely aggressive scheduler is a scheduler that never delays an operation; 
it rejects operations that violate its scheduling policy. A practical scheduler 
that generates priority committed histories will probably not be a purely 
aggressive scheduler. With a purely aggressive scheduler, if Tj were ordered 
before T), Tj X Tj, Tj were active, and Tj submitted a commit, a purely 
aggressive scheduler would have to abort Tj. This abort could be unneces- 
sary; if instead the scheduler delayed the commit until Tj committed, the 
history would still be priority committed. 


2 Priority Serialization Graph Testing 

Serialization graph testing schedulers (or SGT schedulers) [6,2] guarantee 
serializable executions by maintaining a serialization graph. This graph 
contains nodes for all active and “relevant” committed transactions (de- 
scribed below). The scheduler ensures this graph contains no cycles, thus 
guaranteeing a serializable history. 
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SGT schedulers are more of theoretical than practical interest. They are 
easy to understand and argue correct, but the overhead of maintaining a 
serialization graph may not justify any increase in concurrency over other 
schedulers. In this section, a SGT scheduler will be extended to avoid prior- 
ity inversions. This extension increases the complexity of the scheduler. In 
particular, much of the simplicity of SGT schedulers comes from aborting 
a transaction only when it submits an operation. As noted in section 1, 
this policy cannot be used when avoiding priority inversion. 

A SGT scheduler operates as follows. When a transaction T, submits an 
operation p.x, the scheduler tentatively adds conflict edges from all vertices 
Tj to Ti if there exists an operation q 3 x executed earlier that conflicts with 
PiX. If piX creates a cycle in the serialization graph, the scheduler aborts 
Ti, since the resulting execution would not be serializable. Once aborted, 
T, is removed from the graph along with all edges either into or out of T,. 
If piX does not create a cycle, the tentative edges can be made permanent 
and the operation executed. 

To ensure the executed instructions are recoverable, the scheduler delays 
the commit from T, until all transactions from which T t read have also com- 
mitted. Once Ti has committed, T, can be removed from the serialization 
graph when it cannot be involved in any future cycles. Since all operations 
after T,’s commit will be ordered after T x , any new edges will be added lead- 
ing out of Ti. This means Ti can be removed when there are no edges in the 
graph leading into Tj. We will assume such transactions are automatically 
removed. 

A priority serialization graph testing scheduler (or PSGT scheduler) follows 
a similar strategy, with the caveats outlined in section 1. In particular, the 
rejection strategy of SGT c an cause a priority inversion. Instead of aborting 
the transaction that submitted the operation, we may have to abort a 
transaction with less priority. By generating priority commit histories, we 
will always be able to abort such transactions. 

However, this strategy complicates the scheduler. If the submitted oper- 
ation is a write, it could conflict with several unordered reads. Each new 
conflict can create a distinct cycle in the serialization graph. With SGT, 
all cycles are avoided by rejecting the new operation; with PSGT, we may 
have to abort a different transaction from each cycle. 
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Additionally, the PSGT scheduler will need to avoid priority inversions 
caused by cascaded aborts. The scheduler can do so by maintaining a 
RFG and checking for priority inversion cycles. Maintenance of a RFG 
is not as straightforward as a serialization graph. When a transaction is 
aborted, the reads- from relation changes which in turn may introduce new 
priority inversion cycles. For example, consider the following history where 
T 0 yT u T 2 ,T 3 . 


WiX ; w 2 x ; w 3 x\ r 0 x 


The only priority inversion cycle is (To, T 3 ). Once T 3 is aborted, the cycle 
(T 0 , T 2 ) is created, and when T 2 is aborted the cycle (To, T\) is created. 

One way simplify detecting and removing priority inversion cycles is to 
augment the RFG. An augmented RFG will contain a vertex for each active 
transaction, and three kinds of edges: 

1 . Priority edges, as in a RFG. 

2. Read-from edges, as in a RFG , except that the edge is labeled with 
the name of the variable that was read. 

3. Write-after edges, also labeled with the name of a variable. When 
a transaction T, writes a variable x, a write-after edge labeled x is 
drawn from the last transaction that wrote x (if it is still active) to 
Ti. 

When a read-from edge is added to the augmented RFG, the graph can 
be traversed to determine which transactions should be aborted. Let the 
function Abort(T, v, p ) be the set of transactions that must be aborted due 
to the read of variable v written by T; p is the priority of the transaction 
that submitted the original read operation. The functions read(T, x) and 
write(T, x) encode the reads-from and write-after edges; i.e. they are the 
transaction from which T read x and wrote x after, respectively. Abort is 
recursively defined as follows. 
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Abort(T, v, p) = 

if p X T -+{T} U Abort(write(T, v), v, p) 

□ p ^ T — variables w read by T: 

Uu, Abort(read(T, w), w, p) 

fi 

Figure 2 shows an example, where write-from edges are drawn as doubled 
arrows. When T\ submits rjx, the function Abort(T 2 ,x, T\) is evaluated, 
yielding { 23 , 74 }. T 2 will also be aborted as a cascaded abort. 



Figure 2: Aborts, x,T\) = {73, 7 4 } 

A PSGT scheduler executes as follows. Let T, be a transaction that has 
submitted an operation p,x to the scheduler. 

• If pi is a read or write operation: 

1. Add the operation to the serialization graph as described above. 
Let C be the set of cycles created by adding the new edges. If 
|C| = 0, skip to step 3. 
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2. If T, can be aborted without introducing a priority inversion; i.e. 

3c 6 C : VT, € c : T, ^ T, 

then reject the submitted operation, abort transaction T t and 
await the next submitted operation. Otherwise, choose a set of 
transactions from the cycles in C that, when aborted, will remove 
all cycles (the selection process will be described shortly); abort 
these transactions, and proceed with step 3. 

3. Add the appropriate edge to the augmented RFG. If the oper- 
ation is a read, determine the set of transactions to abort, and 
abort them. The transaction that must be aborted are those in 
Abort(read(Tj, x, T,). 

• If pi is a commit operation, the scheduler must ensure the history is 
priority committed. The commit operation is delayed until all trans- 
actions ordered earlier than T, in the serialization graph are either 
committed or of less or incomparable priority. 

PGST maintains serializability in the same way SGT does; by maintaining 
an acyclic serialization graph. PGST avoids priority inversion by the (as yet 
unspecified) method used to select transactions to abort, described next. 

Not all of the cycles in C need to be distinct; there can be cycles c\, c 2 such 
that ci flc 2 D {T,}. Note that if Ci C c 2 , c 2 is broken when ci is broken, and 
c\ must be broken. In order to reduce the number of aborted transactions, 
the scheduler should examine the cycles in order of ascending length. The 
scheduler accumulates a list of transactions A to abort; if, when examining a 
cycle c, it is found that «4flc ^ 0, the scheduler need not select a transaction 
from c to abort. Otherwise, the scheduler can choose any active transaction 
from c; by the property of priority committed histories, any one with less 
priority relative to T, is still active. 

Some issues have been glossed over for brevity. For example, the aug- 
mented RFG must be updated when transactions from C are aborted, and 
a transaction must be able to find the value of a variable after a cascaded 
abort. 
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3 


Preemptive Two— Phase Locking 


If we assume >- is connected (i.e. all processes have comparable priorities), 
two-phase locking ([3], [2]) can be easily extended to detect and eliminate 
priority inversion. Basic strict two-phase locking uses the following rules: 

1. A transaction Ti acquires a lock on a data item before referencing the 
item. These locks are typically read or write locks (also called share 
and exclusive locks) depending on the submitted operation. T, delays 
until the required lock is available. 

2. All locks held by T, are released after T, commits. 

In order to avoid priority inversion, a preemptive version of two-phase lock- 
ing ( P2PL ) cn be used. When T) tries to acquire a lock, it waits until either 
the lock is free or all processes holding the lock with conflicting access have 
less priority. In the latter case, the scheduler then aborts the transactions 
holding the lock and gives it to T,. Since all committed transactions follow 
the original two-phase rules, P2PL generates serializable histories. Ad- 
ditionally, while 2PL is susceptible to deadlock, P2PL limits deadlock to 
occur only among transaction with the same priority. If a set of deadlocked 
processes have different priorities, there must exist a priority inversion, and 
P2PL will detect it and remove it. 

P2PL does not have cascaded aborts, so it cannot generate priority inversion 
cycles in the RFG. A transaction T, reads from another transaction T, only 
after Tj commits, and only active transactions are in the RFG, so the RFG 
will contain no reads -from edges. 

P2PL generates priority committed histories without additional delays at 
commit. If T, is ordered before Tj , either there exists two conflicting 
operations < qjX or there exists a transaction Tk such that Ti is or- 
dered before Tk and T* is ordered before Tj. For strict two-phase locking, 
(piX < qjx) =>• (ci < Cj ), and since the commits form a total order, if 
(Ti ordered before Tj) =► (c, < Cj). This simplicity comes at a cost, how- 
ever. For example, consider the submitted history Wix\ iuix; C 2 ; c* where 
T\ >- Tj. Under PSGT, the commit from T 2 is delayed until after the 
commit of 7\; under P2PL, T 2 is aborted by the write from Tj. 
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As it currently stands, P2PL does not detect priority inversions with non- 
connected orders. Let T U T 2 ,T 3 have priorities T 2 y T 3 , and let T 3 acquire 
an exclusive lock on x and T\ acquire an exclusive lock on y. If T\ attempts 
to acquire the lock on x it will block since T\ )/■ T 3 . If T 2 then attempts to 
acquire the lock on y it too will block since T 2 )f T\. We now have T 2 transi- 
tively blocked on T 3 , which is a priority inversion. Extending P2PL to work 
with partial priority orders complicates the algorithm; it must examine the 
owner of all locks held by processes transitively blocking the request. 


4 Priority Timestamp Order 

Timestamp order (TO) schedulers ([9], [2]) operate by assigning transac- 
tions a timestamp when they start. The timestamp, typically an integer, 
places the transaction in a total order with respect to all other transactions. 
The scheduler ensures operations occur in an order consistent with the total 
timestamp order. Since the transactions are totally ordered, the history is 
serializable. The scheduler typically assigns timestamps in the order the 
transactions start, but this is not necessary; the scheduler guarantees the 
operations respect any order assigned by the timestamp allocation rule. 

Associated with each variable x in the data base is a read stamp x.r and a 
write stamp x.w. These stamps are the timestamps of the last transaction 
to read and write x respectively. When T, with timestamp s, submits an 
operation to a TO scheduler: 

1. If it is a read operation: if s, < x.w then the read is too late and 7 1 , is 
aborted; otherwise, x.r is set to Si and the read is executed. 

2. If it is a write operation: if s, < x.r then this write is too late and T, 
is aborted; otherwise, the write is executed if s, > x.w, and x.w is set 
to Si. 

3. If it is a commit operation, it is delayed until all transactions that 
Ti has read from have committed. There are several ways to achieve 
this property ([2]). 

A timestamp concurrency control algorithm that detects priority inversion 
( PTO ) allocates timestamps such that priority inversion cycles in the RFG 
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cannot occur. A timestamp S{ for T; is uniquely allocated from a total order 
such that it meets the following two conditions: 

1. For all committed transactions T*, s, > s k . 

2. For all active transactions Ty. if Tj y Ti then s, > sj and if T, y Tj 
then Sj > $i. 

The first condition is the same as for typical TO schedulers: to do otherwise 
implies the later transaction must appear to have run before a committed 
transaction. The second condition guarantees that the RFG will contain 
no priority inversion cycles: a reads from edge cannot go from a transaction 
with less priority to one with more priority. Since the timestamps have a 
total order, there can be no reads from path from a transaction with less 
priority to one with more priority. 

It is not difficult to generate timestamps that obey the above two conditions. 
If a timestamp is represented as a number, the number space must be dense. 
Consider transactions Tj with timestamp Sj and T, y Tj with timestamp 
Si < Sj. For any n, if n new transactions start with priority between T, and 
Tj, n timestamps with values s,- < s < Sj must be assigned. In practice this 
shouldn’t be a real problem, and in extreme cases the scheduler can abort 

Ty 

PTO must use a different comparison rule than TO. With TO, a transaction 
is aborted if it submits its operation too late: that is, it has too low a 
timestamp. Under PTO the transaction with more priority could be the 
one that is late, so the transaction that acted too early should be aborted. 
Like PSGT, there can be several such transactions that acted too early. For 
example, consider the history w*x\ r 3 x; w\x where T\ y T^y T 3 . The first 
two operations happened too soon, and T-j and T 3 are aborted. Instead of 
associating a single read and write timestamp with a variable, a list of read 
timestamps and write timestamps must be kept. For recoverability, each 
list must contain at least one timestamp from a committed transaction. 
This lists can grow arbitrarily long, but in practice this shouldn’t be a real 
problem. A timestamp can be removed from a list if the list contains a larger 
timestamp of a committed transaction. In extreme cases, the scheduler can 
abort the active transaction with the largest timestamp; e.g. transaction 
Tj in the example above. 


13 


Since it is necessary to store lists of timestamps, the value of a write can 
also be stored with its timestamp. By doing so, fewer aborts will occur 
since a write can never be done too early. A database that stores histories 
of variables is called a multiverison database ([2,5]). 

When Ti with timestamp s, submits an operations, PTO uses the following 
rules: 

1. If it is a read operation: Si is entered into x.r. The largest entry s in 
x.w such that s < S{ is found, and the value written at that time is 
returned. 

2. If it is a write operation: Si is entered into x.w along with the value 
being written. Let s be the smallest timestamp in x.w greater than 
Si, or oo if Si is the largest timestamp. All transactions T* in x.r that 
have timestamps in the range s, < s* < s are aborted (there may be 
no such transactions), as they read x too early. 

3. If it is a commit operation, it is delayed until all transactions with 
timestamps less than s; have committed. Once the transaction suc- 
cessfully commits, for each variable x in T.’s read (c/. write) set, the 
timestamp lists x.r (cf. x.w) can be truncated: all timestamps less 
than Si can be removed. 

When a transaction Tj is aborted, its timestamps are removed from all 
variable timestamp lists. Additionally, transactions that read from Tj must 
also be aborted. For each variable x in T/s write set, let s be the smallest 
time stamp in x.w that is larger than Sj, or oo if no such timestamp exists. 
All transactions T* in x.r such that Sj < Sk < s read from Tj, so they are 
aborted. 

PTO ensures serializability by using timestamps from a total order, and 
ensures there are no priority inversions for recoverability by its timestamp 
generation rule. The main weakness with PTO is the delay in the commit 
rule. Suppose a transaction only wishes to update x but is started at 
the same time a long-running transaction with more priority is active. 
Even if the two transactions never reference the same variables, the shorter 
transaction must wait for the longer running transaction to complete. With 
both P2PL and PSGT, the shorter transaction will be able to complete 
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without delay. For PTO to do similarly, it must either maintain the actual 
reads from relation as PSGT does, or know more information about the 
transactions (such as a transaction’s read set and write set). 


5 Discussion 

This paper examined three common concurrency control algorithms and 
showed how each could be extended to avoid priority inversion. The results 
are mixed: 

• Without some knowledge of the transactions that will be submitted, 
there are no purely conservative concurrency control schedulers nor 
any practical purely aggressive concurrency control schedulers that 
avoid priority inversion. 

• Traditional aggressive schedulers, like serialization graph testing and 
timestamp order schedulers abort a transaction by rejecting an op- 
eration when submitted. This method cannot be used when priority 
inversion must be avoided. Instead, a transaction that submitted its 
operation earler must be aborted, so the more urgent transaction can 
continue. This policy increases the complexity of aggressive sched- 
ulers. In the case of serialization graph testing, it isn’t clear that 
the increased concurrency would ever compensate for the increased 
complexity, given a reasonable workload. 

• The traditional conservative scheduler, two phase locking, can be eas- 
ily extended to avoid priority inversion when the priority relation is 
connected. The extension for nonconnected priorities is somewhat 
more complex. 

• Timestamp order schedulers, when extended to avoid priority inver- 
sion, suggest using a multiversion concurrency control algorithm. The 
extended algorithm is not much more complex than a traditional mul- 
tiversion timestamp order algorithm. However, transactions with less 
priority can be needlessly delayed unless read sets and write sets are 
declared when a transaction starts. 
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The algorithms presented here have not been implemented, and their rela- 
tive performance has not been examined in any detail. Additionally, only 
the priorities of transactions has been to schedule or abort operations. 
Other information could be used, such as the remaining running time of a 
transaction ([1]). It isn’t clear what kind of information would be useful 
for the more aggressive schedulers. 

These algorithms were developed as part of the Cornell RR Project , where 
which we are developing both theory and tools for building real-time reli- 
able systems. Part of this project is the development of a process control 
system, which will eventually contain a database-like component. Our 
next step with the algorithms in this paper will be to evaluate them in the 
context of the RR project. 
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